Programmable logic devices (PLDs) are a well-known type of integrated circuit that can be programmed to perform specified logic functions. One type of PLD, the field programmable gate array (FPGA), typically includes an array of programmable tiles. These programmable tiles can include, for example, input/output blocks (IOBs), configurable logic blocks (CLBs), dedicated random access memory blocks (BRAM), multipliers, digital signal processing blocks (DSPs), processors, clock managers, delay lock loops (DLLs), and so forth.
Another type of PLD is the Complex Programmable Logic Device, or CPLD. A CPLD includes two or more “function blocks” connected together and to input/output (I/O) resources by an interconnect switch matrix. Each function block of the CPLD includes a two-level AND/OR structure similar to those used in Programmable Logic Arrays (PLAs) and Programmable Array Logic (PAL) devices. In some CPLDs, configuration data is stored on-chip in non-volatile memory. In other CPLDs, configuration data is stored on-chip in non-volatile memory, then downloaded to volatile memory as part of an initial configuration sequence.
For all of these programmable logic devices (PLDs), the functionality of the device is controlled by configuration data bits provided to the device for that purpose. The data bits can be stored in volatile memory (e.g., static memory cells, as in FPGAs and some CPLDs), in non-volatile memory (e.g., FLASH memory, as in some CPLDs), or in any other type of memory cell.
Other PLDs are programmed by applying a processing layer, such as a metal layer, that programmably interconnects the various elements on the device. These PLDs are known as mask programmable devices. PLDs can also be implemented in other ways, e.g., using fuse or antifuse technology. The terms “PLD” and “programmable logic device” include but are not limited to these exemplary devices, as well as encompassing devices that are only partially programmable.
An error detected during operation of a PLD may generally be traced to either a design flaw or faulty circuitry within the PLD. In response to detecting an error, various diagnostic measures may be performed to learn and correct the source of an error. Various function tests may be performed on a design implemented on a PLD in order to identify an error in the design. If a design error is identified, the design may be changed and the PLD reconfigured with the implementation of the corrected design.
If a design error is ruled out, various tests may be performed on the PLD to determine whether the circuitry on the PLD is defective. Depending on the design requirements and extent of defective circuitry, a PLD with defective circuitry may still be usable by recompiling the design to exclude use of the defective components on the PLD. Alternatively, a failing part may be removed from an application system and submitted for root cause analysis. The part may be removed and further tested in order to identify the exact location of failure in order to determine the cause of failure and initiate a corrective action to prevent subsequent failures.
Determining the location and extent of the faulty circuitry may involve substantial manually performed operations. At present, tests are available to identify failing logic blocks on a die. Once a failing CLB has been identified using the equivalent of a standard test vector set, a CAD tool may be required to manually tap and route test points on the input and outputs of the identified failing circuit block to available unused peripheral IO pins and rewrite the test program to compare the new outputs to expected values. The expected values must be calculated based on examination of the logic design. By process of elimination the failing path may be determined.
Once the failing path is identified, the path may be highlighted in a CAD tool and the coordinates recorded for all points along the path. This information may be used to recreate the path on the failing part once the part has been cleared of all other configurations. After the part has been reconfigured with the failing path isolated, the coordinates of the points where the failing signal is routed through the programmable routing matrix and recorded. Once these points are known, these points need to be manually tapped and routed to available I/O pins, and the test program must be rewritten to monitor these IO pins compared to a calculated expected output. The failing output identifies the failing node.
The present invention may address one or more of the above issues.